整个工程的反思和收获

1. 做的好的

1. 首先还是比较幸运能够全程参与到整个开发过程中，几乎算是让我一个人从 0 开始，技术选型、poc、搭建、推进整个过程了，对于一个非常成熟的产品来说，下定决心从新开始升级是比较需要胆量和决心的。IDE 作为前端深水区，这个方向的选择上以及坚持，无论是对我个人还是对前端团队来说，机会都是很大的。
2. 在大家可能都不了解一项技术或者框架的前提之下（或者了解不深）， 最需要做的是，进行技术调研，快速出 demo 并做完善的技术评审。 如果没有结论或者有同学有异议，技术评审还需要一直做，直到大家都没有疑问了之后，在开始快跑。作为一个级别不高的技术同学来说，最后的技术选型敲定，可能不是我来做。但是我前期能够做大量的调研（团队在 IDE 领域前些年可能有所积累，但是几乎没有文档落地），梳理模块文档，一方面是为了让自己更加熟悉，另一方面也是为了让团队的同学更加熟悉，让大家都能够有一个比较好的理解，这样后续的所有意见都有依据。
3. 对开源社区的参与来说，有来有回，也有积极活跃在 github 上，有一个很好的开源社区形象，这对于一个团队来说，也是很重要的。
4. 经过进 2 年时间在 IDE 领域的深耕，我们现在比较有信心，能够在 VS Code 之上几乎能完全实现所有功能（哪怕是支持 React），但是我们还是是比较懂得克制，对于这个新产品来说，不是用新技术实现一遍，而是趁此机会，对于老产品做一次变革，在需要动底座源码的之前，无论如何都会经过多次技术评审，问问自己做这些模块是否是符合 VS Code 设计的，我们做的这些扩展有没有可能贡献到 VS Code 源码中。

2. 做的可能还不够好的

1. 技术选型上

1. Fork VS Code 来搞，直接站在巨人的肩膀上来搞，固然没错，但是跟着社区玩其实是一件蛮难的事。重新让我选择一遍，其实我也并不一定会直接选择 VS Code 了。问题主要体现在：

   1. 周期性更新 VS Code 的代码：
      1. 首先是更新代码意味着合并大量的外部提交的代码，合并本身就是一个大工程，还需要通过单元测试、集成测试等各种手段来保证合入的代码并不会影响原有的功能迭代。
      2. 合并代码是为了解决旧版本的一些问题，但同样也带进来很多新功能，对 VS Code 来说是好事，但是对于一款商业化的产品来说，有很大的解释成本。
   2. 官方对 VS Code Web 的支持度：并不能说特别高，对浏览器的版本要求也挺高的。例如现在最新的 chrome 是 119，但是 CI 测试只跑 109？ 还是多少，官方文档在宏没有说明对浏览器版本的支持情况（还是我提交了一个 issue 建议之后最近才加上的），说法是默认之支持最新的。 当然这也属于无奈之举，必须要在客户和自身的产品迭代之前选择一个权衡。
   3. 贡献核心代码是比较难的。 无论是 bug 还是 feature, 核心一点的 PR 基本上比较难同意合并。
   4. 整体节奏是有微软把控的，而不是业务自己。如果 VS Code 本身有一定的 bug，我们或许可以自行先解决，但是 VS Code 并不一定会这样处理。
   5. 无论我们对 VS Code 的使用有多熟悉，还是有很多占比的功能，是平时很少会接触、打开的。对于 VS Code 功能不符合我们要求的、或者我们还没有回归完整的功能，我们一般情况下是会进行注释，对于产品体验上是会有一定的影响。

2. 基建上

1. 强有力的基建还是很重要的。云构建、CI 大多数都是出于能用（但不好用）的状态，在一款新产品的研发、构建、发布整个生命周期过程中稳健、好用的还是很关键的。

3. 其他

1. 发现自己比较喜欢，通过 issue 或者 CR 的时候的异步沟通方式。